Aurora Serverlessの導入時に気をつけるべきこと
オンデマンドに自動スケールする Amazon Aurora Serverless を採用する機会がありましたので、導入時の参考になりそうなポイントをご紹介します。
まずは結論から
Aurora Serverless はワークロードが大きく変動し、要件がシビアでないシステムに対して、オペレーションコストを下げる目的で導入するのが向いています。
割り切ったシンプルさをそのまま受け入れるのが大事であり、減点主義な環境に導入したり、制約をワークアラウンドでがんばって乗り越えようとするのはオススメしません。
「サーバーレス」の意味を正しく理解する
「サーバーレス」という文字が含まれているので、サーバーレス・アーキテクチャーに特化されたデータベース(どのようなDBなのか興味ありますが)という印象を持ちますが、実態は全く異なります。
「サーバーレス」は「クラスターがオンデマンドで自動スケールするのでプロビジョニングが不要」といったニュアンスです。
「サーバーレス」に惑わされないようにしましょう。
VPC外からアクセスできない
パブリック IP アドレスを割り当てて、VPC 外からアクセスすることはできません。
再開には1分程度かかる
Aurora Serverless は一定時間アイドル状態になったDBクラスタを一時停止できます。
一度停止したクラスタが再開するには1分程度かかります。
そのため、開発環境に Serverless を導入し、朝一でアクセスするとしばらく応答がかえってきません。
この振る舞いは関係者に周知しておきましょう。
ディープヘルスチェックに注意
アプリケーションのヘルスチェックで、依存関係もチェックする事があります(いわゆる「ディープヘルスチェック」)。
長時間のアイドル時は DB クラスターを停止させることを目的に Aurora Serverless を導入する場合、ディープヘルスチェックはやましょう。
一定間隔で DB サーバーへのアクセスが発生するため、アイドル状態にならなくなります。
再起動できない
Aurora Serverlessには「再起動」アクションが定義されていません。
昭和の壊れたテレビは叩けば直ったように、調子の悪いサーバーはとりあえず再起動させたいDBAにおかれましては、カジュアルな障害復旧手段が使えないことに気をつけていただければと思います。
未検証ですが、強制的にキャパシティを変更すると、再起動に近いような動作を得られると思います。
再起動・強制フェイルオーバーに対応してほしいですね。
クエリ処理中はスケールアップできない
Aurora Serverless はシームレスにスケーリングできる スケーリングポイントを起点にスケーリング操作を実行します。
ドキュメントにあるように、以下の条件では スケーリングポイントを見つけられない場合があります。
- 長期実行クエリまたはトランザクションが進行中である
- 一時テーブルまたはテーブルロックが使用中である
重いクエリーをキャパシティー不足な Aurora Serverless に投げても、クエリーをさばけるだけのキャパシティまでスケールアップした上で、クエリーを処理してくれるわけではありません。
スケーリングポイントを見つけられなかったときに、スケーリングポイントの検出を妨げる接続を切断し、強制的にキャパシティー変更するオプションも存在します。
Aurora Serverlessの自動スケールが失敗するときは ForceApplyCapacityChange を有効にしよう! | Developers.IO
なお
- メンテナンスの実行
- パラメーターグループの変更
といった処理も、このスケーリングポイントを起点に行われます。
リザーブドインスタンスに対応していない
通常の RDS インスタンスはリザーブドインスタンス(RI)を購入することで安く利用できますが、Aurora Serverless は RI に対応していません。
- Aurora Serverless を採用してオートスケールさせた場合
- Aurora 非 Serverless を採用してピークキャパシティーや平均キャパシティーに合わせて RI 購入した場合
を机上計算し、ランニングコストを比較しましょう。
Amazon Aurora Serverlessの利用費を試算してみた | Developers.IO
非サーバーレス Aurora に比べて機能制約がある
DB エンジンバージョンの縛りが強い
- MySQL は 5.6系
- PostgreSQL は 10.7系
にしか対応していません。
非サーバーレス Aurora の一部機能を使えない
- Amazon S3 バケットからのデータの読み込み
- データを Amazon S3 バケットに保存する
- Aurora MySQL ネイティブ関数での AWS Lambda 関数の呼び出し
- Aurora レプリカ
- バックトラック
- マルチマスタークラスター
- データベースのクローン化
- IAM データベース認証
- MySQL DB インスタンスからのスナップショットの復元
- Amazon RDS パフォーマンスインサイト
といった機能を Aurora Serverless では利用できません。
フェイルオーバー時間が未定義
Aurora Serverless の DB クラスターは単一のAZに1インスタンスだけ作成します。
インスタンスやAZ障害によりフェイルオーバーが発生すると、別AZにDBインスタンスが作成されます。
高速フェイルーバーには対応しておらず、処理時間は未定義です。
Aurora 系 DB エンジンのフェイルオーバーを整理します。
| DBエンジン | レプリカ | フェイルオーバー方法 | 処理時間 |
|---|---|---|---|
| Serverless | N.A. | 別AZにDBインスタンスを作成 | 未定義 |
| 非Serverless | 無 | 同一AZにDBインスタンスを作成 | 未定義 |
| 非Serverless | 有 | レプリカを昇格 | 30秒以内 |
最後に
MySQL/PostgreSQL 系エンジンを利用していている場合、ダンプを取れば、Serverless/非Serverless Aurora・RDS 間は比較的簡単に移行できます。
検証・開発環境で一度評価してみるのはいかがでしょうか。
